Codecov Report

❌ Patch coverage is 0% with 18 lines in your changes missing coverage. Please review.
✅ Project coverage is 4.71%. Comparing base (1b121b7) to head (2d6cbeb).
⚠️ Report is 607 commits behind head on main.

@@           Coverage Diff            @@
##            main   #1551      +/-   ##
========================================
+ Coverage   3.59%   4.71%   +1.12%     
========================================
  Files         13      35      +22     
  Lines        947    4517    +3570     
  Branches     152     535     +383     
========================================
+ Hits          34     213     +179     
- Misses       843    4299    +3456     
+ Partials      70       5      -65     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

Hi @urfeex , is there any intention to get this merged in the near future? As we are thinking about sim2real implementation, it makes it hard to compare between simulation and hardware. We get most of the information we need time synchronized from /joint_states, but having the effort be incorrect according to the sensor_msgs definition adds an extra layer of annoyance. We can of course strap something together from existing tools, like the RTDE publisher, or building this from source, but just figured I would see the status of this MR bc it is already out there.

This just hasn't been a priority since I drafted out the concept for this. This is basically the case, since there seemingly was no interest in having this available. But I think, I should be able to get this to a mergeable state pretty quickly.

• read the recipe file in the driver, append the torque field if requested and save it as a temporary file that gets passed to the driver object
• Extend the driver config to accept a string vector, as well. Then, we can easily append the field in the hardware interface

We can actually make a combination of both. Since reading the recipe file to a string vector is actually a static method, we can read it in the hardware interface, append the field if possible and then setup the UrDriver object with that vector.

That would be great! It seems like this change shouldn't negatively affect anything, so it would be awesome to have as an option! Thanks for taking a look!

I think the state that it currently is in should be mergeable. This PR needs some polishing, especially on the documentation side, though.

We will be branching out for lyrical pretty soon (before merging #1808), then we can also make this the default on Rolling from that point on.